Add Book to My BookshelfPurchase This Book Online

Chapter 7 - Building a TCP/IP Router-Based Network

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Internetwork Topology
In general, we can identify three classes of service within an internetwork: backbone, distribution, and local services. These three levels of service define a hierarchical design. The backbone services are at the center of the hierarchy, and handle routing of traffic between distribution centers. The distribution centers are responsible for interfacing the backbone to the local services, which are located in each site. At each site, the local services connect individual hosts (multiuser machines and PC workstations) to the distribution network.
In the requirement we have specified above, each major location, such as New York, Atlanta, and Los Angeles, becomes a distribution center, as illustrated in Fig. 7-1. The distribution center concept is a simple one in that it can be used to associate a specific range of IP addresses with one geographic location. This simplifies matters when troubleshooting, can reduce the size of routing tables, and hence can reduce the size of routing updates.
Figure 7-1: Distribution centers connected via a backbone network
This topology gives you the flexibility to implement either a distance vector or link state routing protocol. We shall now look at alternatives for interconnecting sites on the backbone.
Backbone Topologies
The following discussions are based on connecting the main centers together. The goals for this part of the hierarchy are high availability, higher levels of throughput, and the ability to add new distribution centers with a minimum of disruption of service to the internetwork as a whole.
Star Topology.     The star network topology is illustrated in Fig. 7-2, which shows Chicago in the center, with all lines emanating from there to the main locations. This topology is a simple one to understand and troubleshoot. It does, however, place a greater processing burden on the central router located in Chicago, because all traffic passing between distribution centers must pass through that router. In addition, only one full-time connection goes to each location. That means that if one of the main lines from a distribution center to the central site fails, all communication to or from that center stops until some dial backup mechanism reestablishes the link.
Figure 7-2: A backbone network utilizing a star topology
If the bandwidth necessary to provide full communications between a distribution center and the central site is greater than 128 kbps (what is achievable with a single ISDN connection), there are no simple and inexpensive ways to establish a dial backup connection. Multilink PPP is just becoming available, and there are some proprietary ways to perform what is termed inverse multiplexing, the combining of several ISDN connections and making them appear as one line. This could be an option for the star topology if you decide to implement it.
Ring Topology.    The ring topology, as its name suggests, forms a ring around all the main distribution centers (Fig. 7-3). The advantage is that each site has two permanent connections to it, so in the event of a single line failure, an alternate path is available to deliver traffic.
Figure 7-3: A backbone network utilizing a ring topology
The downside is that traffic destined for Dallas from Chicago has to pass along the link from Chicago to New York, then to Atlanta, and finally to Dallas. This places a higher bandwidth utilization on the Chicago-to-New-York link than is necessary, because that link is carrying traffic destined for Dallas. Also, since it uses more lines than the star topology, there is less likely to be money for a dial backup system, which is okay since there are two lines feeding each location. If any two lines fail, however, the network is down hard until one of them comes back.
Fully Meshed Topology.    This is the ultimate in resiliency, minimizing the number of intermediate routers through which traffic must pass, and reducing the amount of traffic on each link. The obvious drawback is the cost of all the leased lines. There are very few situations that justify a fully meshed network, because just adding one more distribution center to the backbone takes up significant resources in terms of router ports at each location. A fully meshed network is shown in Fig. 7-4.
Figure 7-4: A backbone network utilizing a fully meshed topology
Partially Meshed Topology.     The concept behind the partially meshed network should be familiar to all those who have been involved in internetwork design, and that concept is compromise. The partially meshed network, as illustrated in Fig. 7-5, adds a few cross- connect lines to the ring topology, but not quite as many as would a fully meshed network. This is the most popular form of internetwork backbone because it can be adjusted to suit the requirements of the organization. Typically, the more important locations will receive the most connections feeding it. Also, network redundancy can be added as required, without the need to redesign the whole topology.
Figure 7-5: A backbone network utilizing a partially meshed topology
A backbone of this design does not rely on dial backup of its links; rather, it assumes that at least one of the main lines feeding each distribution center will be up at all times. Having alternate paths available in case of line failure complicates the process of deciding what size link to install between distribution centers. Let's say it is estimated that a 128 kbps line will adequately handle the traffic requirements between New York and Atlanta under normal conditions in the internetwork illustrated in Fig. 7-5.
Now suppose the link between Dallas and Atlanta fails. Assuming that a dynamic routing protocol of some kind is in operation, traffic between Dallas and Atlanta will be routed through Chicago, New York, and on to Atlanta. The link between New York and Atlanta is now carrying its normal load, plus whatever normally flows between Dallas and Atlanta. If the combined level of this traffic is significantly above 128 kbps, the effects could be disastrous for the inter-network. If the combined traffic is, say, in the region of 160 kbps, backbone routers will begin to drop packets as soon as buffers start to overflow.
If this traffic is based on a connectionless protocol (like UDP), the data is merely missed, but if the traffic utilizes a connection-oriented protocol (such as TCP), even more traffic will be sent as retransmissions occur. This effect causes the New-York-to-Atlanta link to be overutilized and thus virtually unusable.
In this scenario, having an alternate path has made things even worse. Instead of the line failure affecting communication only between Dallas and Atlanta, it now adversely affects New-York-to-Atlanta traffic, and potentially Dallas-to-Chicago traffic, and Chicago-to-New-York traffic as well. As a general guideline, if you are going to rely on alternate paths to provide backup in the event of a link failure, backbone links should be no more than 50 percent utilized under normal conditions.
The Public Network Concept.     The public network concept means that you delegate to a network vendor the management of the backbone and distribution center internetworking issues. Typically you will provide a single link (with optional dial backup, or duplicate leased line) from each remote site to the network vendor's cloud, and leave it up to the vendor to deliver the traffic to the main office location.
This type of approach has become popular with frame relay networks, as discussed more fully in Chap. 6. A frame relay solution even can be used to eliminate the need for distribution centers, as each office location could be linked directly to the frame relay service. Frame relay services became popular when frame relay vendors were trying to introduce the technology. Often a company could buy a very low CIR, and hence pay very little for the connectivity in relative terms, yet still get acceptable throughput. The reason for this was that the frame relay networks had surplus capacity.
This was not a frame relay vendor's idea of a good deal. From a vendor's perspective, the goal is to oversubscribe the shared network and thus lower costs, resulting in higher profits for the vendor and lowered prices for customers. This may seem a harsh judgment, but I know of many companies that bought a very cheap 4 kbps or so CIR and were very happy with its performance to begin with (often they were able to get burst rates of throughput of over 100 kbps), but became unhappy when the frame relay service became more popular and their allowable throughput diminished to much nearer 4 kbps, which made the network useless from their perspective.
The simple solution is to increase the CIR and pay the network vendor more money. I believe, however, that internetworks are there to provide users with reliable and responsive service to applications. If you need 64 kbps to do that, you need a 64 kbps CIR, which might start to approach the costs of having your own dedicated bandwidth. The bottom line is that with your own dedicated bandwidth, you are master of your own destiny and have a degree of certainty over how your internetwork will perform. It all depends on the nature of the traffic you have to transport; if all you need to get to users is Internet, e-mail, and occasional file transfer capabilities, frame relay or some other shared network solution might meet your needs. If you have to deliver mission-critical applications and therefore need guaranteed uptimes and response times, you need your own bandwidth.
Distribution Center Topologies
Conceptually, anything that was done with the backbone could be repeated for the distribution centers to interconnect individual sites to the internetwork. However, the distribution centers have a different function to perform than the backbone links and routers, which makes the star topology with dial backup by far the most common choice.
The link between a distribution center and a particular office where users are located has to carry traffic only for that office and therefore has a lower bandwidth requirement than does a backbone link. This makes dial backup utilizing technologies such as ISDN more attractive, as the dial-up link in this situation is more likely to be able to handle the traffic. The other network topologies are feasible, but the cost is rarely justified.
Assuming that at the distribution level we have individual links going from the distribution center to each site, we have a choice to make regarding dial backup. We can provide no dial backup if the network connection is not mission-critical, provide dial backup to the distribution center, or provide a central dial backup solution at the head office.
Deciding whether to provide one central pool of dial ports or distributed ports at each distribution point depends on what the users at each site ultimately need to access. Given that the remote sites need access to head office hosts, we have to consider where other servers, such as e-mail and office automation servers, will be located. The options for locations for these types of servers are the head office, the distribution center, and the remote site.
The most efficient design from the perspective of dial-up port utilization is to provide one central pool of ports. This enables you to provide the least number of ports and still provide sufficient backup capability for realistic network outages. If separate pools of ports are made available at each distribution center, more ports overall are necessary to provide adequate cover.
If all services to which users need access over the internetwork are located at the head office, it makes sense to go with one pool of ports located at the head office. If the user sites need access to servers located at the distribution centers as well as at the head office, it makes more sense to provide individual dial-up pools at the distribution centers.
There is one additional benefit to providing a central dial-up pool at the head office, and that is if a major outage that affects the whole internetwork, the dial-up pool can be used to bypass the internetwork. That option is not available with distributed dial-up pools in the distribution centers. There might be a slim chance that something will happen to bring down the entire internetwork, but it is not unheard of. More than one well-known long-distance telephone company has had problems on its network that have affected regional and even national data services.
All of this seems quite simple and is basically common sense; the decision of where to locate the dial-up ports, however, is inexorably linked to the IP addressing scheme used and the routing protocol implemented. Route summarization is a feature of IP networking using distance vector routing protocols such as IGRP. Let's discuss what this means with reference to Fig. 7-6.
Figure 7-6: IP addressing scheme that requires sites to use dial backup located in thedistribution center
This figure shows an internetwork utilizing the addresses reserved by the InterNIC for companies using network address translation to connect to the Internet. The backbone uses the Class B network number and the distribution centers use Class C addresses implemented with a 255.255.255.224 subnet mask. This gives six subnets, each supporting a maximum of 30 hosts. Assuming that a distance vector routing protocol is in use, route summarization means that the distribution center shown will only advertise each Class C network back to the backbone, as the backbone is a different network number. Under normal conditions this is okay, because traffic traveling from the head office network to a Class C subnet will take the same path through the backbone until it reaches the distribution center. If, however, site A in Fig. 7-6 loses its link to the distribution center and dials in to a central pool of dial-up ports, we have a problem. We now have two physical connections between the 172.16.0.0 network and the 192.168.1.0 network.
In this situation, routers at the head office will have to choose between a route to the 192.168.1.0 network via the dial-up port, or through the backbone. This is because the routing tables in the head office routers will accept only whole network number for networks that are not directly connected. What ends up happening is that whichever of the two routes to 193.168.1.0 has the lowest metric is the one that gets entered in the head office routing tables, and the other route to the 193.168.1.0 network will never get traffic.
If this network numbering scheme is chosen, distributed dial-up port pools are the only option. If the whole internetwork was based on the one Class A or Class B network, appropriately subnetted, either central or distributed dial-up port pools would work. This is because all sites are on the same major network number and subnet mask information is utilized throughout the internetwork to identify where individual subnets are physically attached.
Head Office and Remote Site Topologies
At a user site, such as site A in Fig. 7-6, the on-site router connects the site LAN to the distribution center and initiates dial backup when needed. A host machine such as a user PC typically will be configured for one router address as the default router, sometimes referred to as the default gateway. This means that if the PC has to send traffic to a network address that is not on the directly connected segment, it will send the traffic to the default router, which will be expected to handle routing of traffic through the distribution and backbone networks. This becomes a problem only if the site router fails, but this is a rare occurrence and should be easily and quickly fixed by a hardware swap-out.
This type of routing is fine for a user site that services up to 20 or so single-user PCs, but it might not serve the needs of the central site with multiuser hosts that are accessed by more than 100 remote offices. To eliminate the central router as a single point of failure, Cisco has developed the Hot Standby Router Protocol (HSRP), a proprietary mechanism for providing the functionality of the IETF's Router Discovery Protocol (IRDP).
The functionality these protocols provide can best be explained with reference to Fig. 7-7, which shows how the WAN interconnections illustrated in Fig. 7-5 may be implemented with physical hardware for the Chicago head office.
Figure 7-7: A potential network configuration for the Chicago head office
If hosts 1 through 3 are configured using default gateways, each host will send all traffic destined for remote network numbers to its default gateway. What happens if this router fails? All the router devices on the network (assuming that a routing protocol such as IGRP is in use) will adjust their routing tables to reflect this change in network topology and will recalculate new paths to route around the failure. The hosts, however, do not run IGRP and cannot participate in this process. The hosts will continue sending traffic destined for remote networks to the failed router and remote access to the hosts will not be restored.
IRDP is a mechanism that requires a host TCP/IP stack that is IRDP-aware. A host that uses IRDP to get around this problem listens for hello packets from the router it is using to get to remote networks. If the hello packets stop arriving, the host will start using another router to get to remote networks. Unfortunately not all hosts support IRDP, and to support these non-IRDP hosts, Cisco developed HSRP.
To implement HSRP, you manually configure each host to use a default gateway IP address of a router that does not physically exist, in essence a "ghost" router, which is referred to in the Cisco documentation as a phantom. In Fig. 7-7, router 1 and router 2 will be configured to provide HSRP functionality to hosts 1 through 3. To achieve this, we enable HSRP on router 1 and router 2 and configure them to respond to hosts sending traffic to the phantom router MAC address. Note that you do not configure the phantom's MAC address anywhere; you just assign an IP address for the phantom in the configuration of routers 1 and 2 that matches the default gateway IP address configured in the hosts. Whichever of router 1 or router 2 gets elected as the active router will respond to ARP requests for the phantom's MAC address with a MAC address allocated from a pool of Cisco MAC addresses reserved for phantoms.
Using the addressing scheme of Fig. 7-7, we could define the default gateway for all hosts as 193.1.1.6. The process by which one of these hosts delivers a packet to a remote client PC, e.g., 200.1.1.1, would be like this:
  The destination network is not 193.1.1.0, therefore the host will send the packet to the default gateway.
  The ARP table will be referenced to determine the MAC address of the default gateway.
  A packet will be formed with the destination IP address of 200.1.1.1 and with destination MAC address as that of the default gateway.
Routers 1 and 2 will be configured to run HSRP, which at boot time elects one of the routers as the active HSRP router. This active router will respond to all traffic sent to the MAC address of the device numbered 193.1.1.6. Routers 1 and 2 will continually exchange hello packets and in the event the active router becomes unavailable, the standby router will take over routing packets addressed to the MAC address of the phantom router.
To enable HSRP on routers 1 and 2, the following configuration commands need to be entered for both routers:
Router(config)#interface Ethernet 0
Router(config-int)#standby ip 193.1.1.6
Any host ARP requests for the MAC address of 193.1.1.6 will be answered by the active router. As long as the active router is up, it will handle all packets sent to the phantom router, and if the active router fails, the standby router takes over routing responsibility for the phantom router with no change in configuration or ARP tables of the hosts.
Designing Physical Network Layout
Each networking technology has its own physical restrictions and requirements within its own specifications. There are, however, some generic guidelines that are useful when designing an internetwork that has to provide a high degree of availability.
Communication Vendor Issues.     The first thing to consider if you are going to install ISDN links as dial backups to the main communication lines is that the leased lines and ISDN lines likely will be provided by different vendors and delivered to a site by separate networks. If the ISDN and main link are provided by one vendor service to one of your remote locations which, then experiences a lack of service due to problems at one of your communication vendor's central offices, going to dial backup is unlikely to help, as the ISDN connection most likely will be routed through the same central office that is experiencing problems.
There are additional issues to consider for a central site. Typically at a central site that is housing the multiuser hosts accessed by the remote branches, you should seek to have two points of access to your communication vendor's facilities. In most major metropolitan areas, high-speed communication links are being delivered on fiber optic SONET (can also be referred to as SDH) rings. The idea behind this is that placing a central site on a SONET ring enables the communication vendor to have two physical routes to your central site, and if one side of the ring is broken, the vendor can always get traffic to you by using the other side.
This works only if the two fiber cables being used to deliver the service to your central site never use the same physical path. This means there must be two points of access to your building so that the fibers can be diversely routed into your premises. I have seen several organizations that had hoped to reap the reliability benefits of being on a SONET ring but were unable to do so because both fibers were pulled through the same access point to the building. In this case, if one fiber gets broken, for example, if road workers break all cables going into one side of your building, both fibers will be broken, thus taking away part of the benefit of being on a SONET ring.
In metropolitan areas, many sites will be serviced with fiber links directly to the building. In less densely populated areas, communication vendors typically have to extend service to a building using a direct copper link of some kind. Typically it is not cost-justified for a communication vendor to extend a SONET ring to a remote area. In the main, this is something you just have to live with. The issue you face is that copper connections are more susceptible to interference than fiber cables, and you should expect more problems getting a copper-connected site operating at full throughput than you would with a fiber-connected site.

 


 
Books24x7.com, Inc © 2000 –  Feedback